hvm: Do not save/restore shared_info gpfn location.
authorkfraser@localhost.localdomain <kfraser@localhost.localdomain>
Mon, 19 Mar 2007 16:48:24 +0000 (16:48 +0000)
committerkfraser@localhost.localdomain <kfraser@localhost.localdomain>
Mon, 19 Mar 2007 16:48:24 +0000 (16:48 +0000)
commit28f7888d7fc4aa75135ac1c566566eda1704db65
tree7497496dd0c56c7c264f3b371d69b95abe50f06b
parentb81cb0e6ae47ee9885ac2bfc006c6e5162d76cae
hvm: Do not save/restore shared_info gpfn location.

Instead of kludging a max_gpfn estimate in shared_info, add a new
XENMEM command to discover the actual maximum gpfn value as known by
the shadow code.

This needs to be more robust when we support HVM ballooning in future
anyway. One interesting point is that max_gpfn may be close to 4GB
even for small-memory HVM guests since for example SVGA LFB is mapped
into the I/O hole. We may need to special case the I/O hole somehow,
or provide some finer-grained way to find out which parts of the GPFN
space are actually used (e.g., get Xen to fill in a bitmap with 1 bit
per 1024 pages, or similar).

Signed-off-by: Keir Fraser <keir@xensource.com>
13 files changed:
tools/libxc/xc_core_x86.c
tools/libxc/xc_hvm_build.c
tools/libxc/xc_hvm_restore.c
tools/libxc/xc_hvm_save.c
tools/libxc/xc_private.c
xen/arch/x86/mm.c
xen/arch/x86/mm/shadow/common.c
xen/common/compat/memory.c
xen/common/memory.c
xen/include/asm-ia64/mm.h
xen/include/asm-powerpc/mm.h
xen/include/asm-x86/mm.h
xen/include/public/memory.h